iT邦幫忙

2026 iThome 鐵人賽

DAY 23
0

前端三分鐘 X 要轉職養豬還是做被取代的工程師?用 Google AI 打造我的 AI 雙刀流自動化工作流系列


在上一篇我們介紹了小幫手 Subagent 的基本概念。但當你真正要把 Subagent 落地到每天的工程開發(或智慧養豬場)時,你一定會遇到一個最核心的實務問題:

「到底什麼任務該留給 Main Agent 做?什麼任務該丟給 Subagent?」

傳統的開發模式就像一個傳統豬農:抓起第一隻豬餵飼料 ➔ 餵完去清豬舍 ➔ 清完去檢查小豬健康 ➔ 最後再去點數量。一項做完才換下一項,完全是阻塞式(Blocking)且低效的。

如果讓你同時顧 1,000 隻豬,這種方法一定會讓你直接崩潰!

要從「單打獨鬥」走向「團隊規模化」,我們必須掌握 Antigravity Subagent 的 Async 非同步分工哲學


一、Async 哲學:擺脫序列阻塞,實現平行派工

官方文件將 Subagent 定位為 Asynchronous(非同步) 運行的獨立 Session。這代表 Parent Agent 不需要停在原地死等,而是可以一口氣同時派發多個任務:

                           [ Main Agent 主豬農 ]
                                     │
           ┌─────────────────────────┼─────────────────────────┐
           ↓ (Async 派發)            ↓ (Async 派發)            ↓ (Async 派發)
     🔍 Research Subagent      🧪 Testing Subagent       🔐 Review Subagent
   (搜尋 10 萬行 Legacy Code)     (背景執行 100+ 測試)     (靜態資安與風格卡關)
           │                         │                         │
           └─────────────────────────┼─────────────────────────┘
                                     ↓
                          Main Agent 接收最終摘要報告

傳統序列阻斷式的工作流:搜尋測試Review決策
非同步平行化工作流:搜尋 + 測試 + Review 同時進行


二、真正關鍵的價值:Context Isolation (上下文護城河)

很多工程師以為 Subagent 只是「讓執行變快」,但 Google 官方明確指出:Subagent 最核心的價值在於 Preserve the Context of your Main Agent(保護主 Agent 上下文不被污染)

想像一下,如果叫 Main Agent 去搜尋一個 10 萬行的 Legacy Codebase:

Main Agent 的腦袋(Context Frame):
「正在思考 Login 元件重構 logic... 檔案 A 讀取... 檔案 B 讀取... 檔案 C 巨量 Log... 檔案 D... 檔案 E...」

當無關的搜尋細節填滿 Context,Main Agent 很快就會發生「前講後忘」或邏輯錯亂(產生幻覺)。

Subagent 的護城河哲學:

  • Main Agent 只專注於「商業邏輯與決策架構」。
  • Subagent 負責進入髒亂的細節戰場(搜尋、巨量檔讀取、測試 Log),最後只將簡明扼要的 3 點結論回傳

三、豬場任務派發決策矩陣表

到底哪些工作適合丟給 Subagent?我們可以用這張表一目了然:

任務類型 適合 Subagent? 關鍵原因與效益分析
全專案 Codebase 搜尋 🟢 極適合 需要大量讀檔與探索,交給 Subagent 可完美避免主 Context 被污染
單元與 E2E 測試執行 🟢 極適合 背景長時間運行,不需要 Main Agent 即時干預
Code Review / 資安 Audit 🟢 極適合 有明確的範疇與獨立 Role,輸出標準化的 Diff 或報告
Browser UI 自動化測試 🟢 極適合 搭配 Antigravity 內建 browser Subagent,可獨立操作瀏覽器
重構架構與研究 🟢 極適合 搭配內建 research Subagent,獨立產出 Summary 報告
小規模檔案改名 / 換型別 🟡 普通 任務太小,派發 Subagent 的 Overhead 成本可能不划算
需要互動式來回對話 🔴 不適合 需要即時決策,Context 隔離反而會增加來回溝通負擔
高度依賴 Main Agent 即時狀態 🔴 不適合 缺乏獨立運行的邊界條件,容易執行偏差

註:Antigravity 本身提供了 researchbrowser 等內建 Subagent,亦支援用 Markdown 自訂專屬 Subagent。


四、Subagent 任務判斷四問公式

當你拿不準這個 Task 該不該分拆時,在心中問自己以下四個問題:

[ 判斷公式 ]
① 這件事能不能由小幫手「獨立完成」?
        ↓
② 能不能明確描述出「輸入 Input」與「輸出 Output」?
        ↓
③ 過程是否需要大量「搜尋 / 測試 / 操作」細節?
        ↓
④ 最終結果是不是只需要「摘要回報」給 Main Agent?
  • 若 4 題多數為 Yes ➔ 毫不猶豫,立刻包成 Subagent 派出去!
  • 若 4 題多數為 No(例如「每做一步都需要問我下一步怎麼辦」) ➔ 留在 Main Agent 執行。

結語:從手藝人到「AI 豬場 CEO」

以前我以為 AI Agent 的進化,是想辦法把「一隻豬」養得越來越聰明。

但深入掌握 Subagent 的 Async 與 Context 隔離哲學後,我才突然醒悟:真正的問題不是怎麼把一隻豬養得更聰明,而是怎麼讓一群豬開始高效率分工!

  • 一隻豬負責找資料(Research Subagent)
  • 一隻豬負責巡豬舍(Browser/Testing Subagent)
  • 一隻豬負責檢查健康(Security Audit Subagent)
  • 一隻豬負責點算數量(Review Subagent)

而我這個豬農,只需要坐在咖啡廳看最後的精華摘要報告報告。

看來……我真的快要轉職成功了! 🐷👷

📝 本日實作作業:

拿出你目前手邊的 Task,嘗試用「四問公式」評估一次,挑選一個最耗費 Context 的搜尋或測試任務,寫成獨立的 Subagent 設定檔吧!

明天 Day 24 一起來看看如果有一天,小豬機器人得比你老闆還要好,我們的生活又會怎麼變化?我們明天見!


上一篇
豬農忙不過來怎麼辦?小豬機器人哪裏找?
系列文
前端三分鐘 X 要轉職養豬還是做被取代的工程師?用 Google AI 打造我的 AI 雙刀流自動化工作流23
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言